[レポート] Developing new findings using machine learning in Amazon GuardDuty #AWSreInforce

はじめに

こんにちは！おのやんです。

先日、AWS re:Inforce 2023にて、機械学習を用いたGuardDutyの開発についてのセッションが行われました。

今回は本セッションについて紹介していこうと思います！

概要

本セッションの概要は以下の通りになっています。

Amazon GuardDuty provides threat detection at scale, helping you quickly identify and remediate security issues with actionable insights and context. In this session, learn how GuardDuty continuously enhances its intelligent threat detection capabilities using purpose-built machine learning models. Discover how new findings are developed for new data sources using novel machine learning techniques and how they are rigorously evaluated. Get a behind-the-scenes look at GuardDuty findings from ideation to production, and learn how this service can help you strengthen your security posture.

Amazon GuardDutyは大規模な脅威検知機能を有しています。そのため、セキュリティ上の問題を素早く見つけて修復できます。このセッションでは、GuardDutyが脅威検出機能を向上させるセキュリティ強化プロセスが紹介されています。そんなGuardDutyの開発プロセスを見ていきましょう。

GuardDutyの進化

GuardDutyが登場して以来、さまざまなソースから脅威を検出できるようになりました。

脅威の検出を行うにあたって、攻撃の際に検出される強い兆候というものがあります。これらは一般によく知られているため、これを目印に脅威の元となるファイルなどを監視することができます。

しかし近年、これらの攻撃手法が巧妙になっています。攻撃者はなんとかしてGurardDutyの検出を逃れようとします。その際に攻撃者は、さきほどの「強力な」方法ではなく、「微弱な」アプローチを取るといいます。すごくわかりにくい弱い攻撃ということですね。こういった攻撃を行ったとしても、環境内の変化が小さいため、検出が難しいケースもあります。フローログの中の数パケットを盗んで持っていったとしても、バレにくいというのです。

GuardDutyでは、このような微弱な脅威を検出できるようにしたいです。

機械学習モデルの構築

GuardDutyが情報源として扱うのは、AWSの各サービスで記録されたイベントです。サービスによってイベントが保持している内容・パラメータは異なります。そのため、これらを機械学習モデルの入力にする場合、どうしても高次元になってしまいます。

ユーザー（ここではAWS開発者）は、すべてのAPIを実行するわけではありません。そのため、元のイベントの高次元状態から、より低次元の空間へ落とし込むことができます。（本セッションでは、この低次元領域のことを「正常領域(Region of Normalcy)」と呼んでいます）。未知の新しいイベントが発生したときに、正常領域に存在しているかどうかを調べることで、異常検出を行うことができます。

イベントが正常領域に存在するかどうかを調べるには、ニューラルネットワークを使います。元のイベントをエンコーダーに通して、低次元の表現ベクトルを生成します。この表現ベクトルは、元のイベントに含まれる情報をすべて含んでいるため、イベントの本質を捉えていると考えることができます。正しいイベントから生成された表現ベクトルは、先ほどの正常領域内に存在します。表現ベクトルは別のデコーダーに渡され、イベントが再構築されます。

つまり、ネットワークに入力したイベントと再構築されたイベントが同じであれば、そのイベントは正常領域に存在するといえます。つまり、正常なイベントだと判断できるわけです。

ここで注意したいのが、コンテキストです。例えば、朝の4時にAWSアカウントへのログインのイベントが発生したとします。これは世間一般で見れば「異常な」イベントである可能性があります。しかし、一部のユーザーにとっては、朝4時にログインすることは「正常な」イベントになり得るのです。この微妙なコンテキストの違いを考慮しながら、モデルを構築する必要があります。

本セッションでは、元のイベントのいくつかの属性を選んでコンテキストを定義しています。このコンテキストをデコーダに渡して、コンテキスト以外の部分を再構築するように設計します。こうすることで、「場合によっては正常だといえるイベント」の影響を極力減らせるわけです。

これらを踏まえて、実際に未知のイベントを入力してみます。新しい未知のイベントを入力した際に、正しく再構築されれば、そのイベントは正常です。

逆に、正しく再構築されない場合、そのイベントは正常領域内の表現ベクトルにエンコードできなかったわけです。これにより、異常なイベントだと判断できます。

このモデルを学習させた後は、本弾環境にデプロイされます。本番環境では、1分間に何百億というイベントを処理していきます。基本的には、各イベントをこのエンコーダーとデコーダーのモデルに渡して、エンコードとデコードを行います。正常なイベントなら正しく再構築されますし、異常なイベントなら「疑いあり」と判断され、後処理に回されます。

モデルの評価

これらの「疑いあり」と判断されたイベントですが、全てが異常であるわけではありません。そのため、まずフィルタリングを行う必要があります。フィルタリングを行うことで、セキュリティ的に問題なさそうなイベントと、セキュリティ的にヤバそうなイベントを分類していきます。

セキュリティ的にヤバそうなイベントに対しては、そのイベントの周辺にある他のイベントやコンテキストを収集・調査します。

これらのプロセスを経て、最終的にGuardDutyの検出結果が生成されるという流れです。

このように学習されたモデルは、正確に評価し、性能を上げることが求められます。

生成されるアラートの数が多すぎず少なすぎずのちょうどいい範囲に収まるようにしました。多すぎるとセキュリティインシデントの調査に影響が出ますし、少なすぎると「本当に検出できてんの？」となりますからね。

それから、検出された脅威を既知の攻撃手法に当てはめ、正確に検出できているかどうかを評価していきます。ここで注意したいのが、検出された脅威が真か偽かを示すラベルがないということです。そこで、実際に検出された際の「兆候」に注目することにしました。少し怪しい程度の兆候なのか、それとも既知の攻撃パターンに見られる兆候なのかを、ここで判断しているわけです。

GuardDutyと機械学習モデルの連携

実際にこの機械学習手法は大きな精度向上を見せました。

コロナ時代になって、開発者のAWSアカウントアクセスの接続元が、AWSオフィスから自宅のインターネットプロバイダに変わりました。従来のGuardDutyではこの変化を「疑いあり」と検知していました。しかし機械学習メインの手法に切り替えててから、そういった変化は脅威として検知されなくなったそうです。

一方で、外国の匿名プロバイダーからのAPIリクエストのような、一般的に考えて普通ではないアクションに対しては、検知数が急増したとのことです。

機械学習モデルの検知がGuardDutyの検出結果になるまでの流れを見てみましょう。

先ほどのモデルは、発生したイベントを入力させてエンコーダー・デコーダーを通して再構築できるかどうかを判別します。通常のイベントを入力した時は、そのイベントは正常領域に存在するため、再構築できます。これは「正常」だと判別されます。

一方で、こちらのDBスナップショットイベントは。Webブラウザのユーザーエージェントから来ていることがわかります。今回のモデルは、このイベントは正常領域には含まれないと判断し、「疑いあり」のフラグを建てます。このイベントは、GuardDutyの処理に渡されていきます。

最初に行されるのは、セキュリティ関連の情報の抽出です。過去の攻撃者の手法や顧客との追跡調査を参考にすると、今回のRDSからDBスナップショットを作成するイベントは、セキュリティ的に気になるというわけです。

それから、そのイベントに関連するイベントを集めていきます。今回のケースだと、IAMの権限を列挙しようとしています。さらにその直後にはRedshift関連のイベントが続きます。Redshift関連のイベントは失敗していますね。これらの情報は、GuardDutyの検出結果を充実察せるためのコンテキスト情報として利用されます。

さらに、このイベントが通常か異常かを判断するコンテキスト情報も調査していきます。これは機械学習モデルではなく、GusrdDuty側で処理されます。今回だと、APIコールが行われるASNは通常どのようなものが想定され、どのようなものが想定外だったのかを確認します。その後、そのイベントをコンテキストで補強してあげます。すると、ASNがプロファイル・データに使用されていないことがわかります。ASN、ユーザーエージェント、API、ユーザー名、ユーザータイプ、アカウントなどはすべて正常です。教師データでも見られるものです。しかし、すべてが組み合わさることで、モデルが異常だと判断することもあります。従来のルールベースのアプローチでは見逃していたような異常なAPIを、機械学習モデルを用いることで検出できるのです。

最後にすべての情報をまとめて、MITREフレームワークに基づいた重要度を割り当て、GuardDutyの検出結果を生成します。

GuardDutyの検出画面では、検出結果がMITREフレームワークによってカテゴリ分けされます。ここでは、検出された異常部分がどの段階にあるのかを確認できます。発見段階の重大度はだいたい低い傾向にあるそうです。それでも、脅威が検出されている状況ならそれらを解決するアクションが必要でしょう。

中段部分を見てみると、異常なAPIがリストとして表示されているのがわかります。これらはAPI呼び出しの成功・失敗 / サービスなどによって分類されています。失敗したアクションが多く見られるなら、ユーザー・権限・環境などさまざまな要因でそのアクションがはじかれていることになります。つまり別のユーザーによって操作されている可能性が高いというわけです。

さらに、AWSのサービスごとに分類することで、より確認しやすくなっています。そのアクションの何が異常なのかも表示されます。

本セッション当日に、GuardDutyの新しい検出結果が発表されました。CloudTrailやS3などのさまざまなAWSサービスに対してモデルが調整されているため、GuardDuty1つで多くのサービスの異常を検知することができます。

まとめ

GuardDutyは、日々進化しています。セキュリティ上の脅威からAWSの環境を守るために、GuardDutyが毎日頑張ってくれています。

みなさんも、まずはお使いのAWSアカウントのGuardDutyを有効化してみましょう。では！